home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Network Support Encyclopedia 13
/
Network Support Encyclopedia (Novell Inc.)(1991).ISO
/
download
/
mpr.txt
< prev
next >
Wrap
Text File
|
1992-05-11
|
21KB
|
388 lines
Overview of MultiProtocol Router Basic
April 15, 1992
NetWare MultiProtocol Router Basic consists of:
> Runtime NetWare 3.11 which allows you to:
- If you do not already own NetWare 3.11 to have a 3.11 router.
- If you already own NetWare 3.11 to set up an additional machine as a
3.11 router.
> 3 router performance enhancement NLMs
1. Burst Mode NLM and Shell
Burst Mode causes a noticeable improvement in NetWare workstation and
server performance. This improvement comes from the NLMs ability to
transfer large amounts of data between servers and workstations in
response to a single data transfer request.
2. Large Internet Packet Exchange NLM
Large Internet Packet Exchange coordinates the packet size between
servers and workstations, synchronizing the largest packet size that
can be transmitted between any two. This optimizes the use of
available bandwidth between any 2 devices, regardless of the packet
size of other devices in the network.
3. Service Advertising Filter NLM
Service Advertising Filter allows system administrators to select
which servers will be visible at various points in the network. A set
of administrator selected attributes are used to specify the type of
access permitted.
MultiProtocol Router Basic is governed by Novell's copyright agreement.
However, Burst Mode NLM, Large Internet Packet Exchange NLM and Service
Advertising Filter may be duplicated by MultiProtocol Router purchasers for
internal use on all servers at their site.
> Documentation for Runtime NetWare 3.11 and the performance enhancement
NLMs.
MultiProtocol Router Basic v1.0 software offers the following features:
- IPX, IP, and AppleTalk routing on Ethernet, Token Ring, LocalTalk,
and ARCnet.
- IPX and IP RIP, AppleTalk RTMP routing protocols.
- Remotely management using RCONSOLE or ACONSOLE. TCP/IP can be
remotely monitored using SNMP (Simple Network Management Protocol).
- Uses standard NetWare security features (encrypted passwords) for
system administration.
- The Router installs the same as another NetWare 3.11 server.
For long distance IPX routing, NetWare Link/64 or Link/T1 can be added to
provide wide area IPX (only) connectivity utilizing the performance
enhancement NLMs. Refer to TN6RUL.TXT in NOVLIB Library 9 of CompuServe
for additional Link/64 and Link/T1 information.
HARDWARE & DRIVERS
> The Network Interface Card (NIC) MUST be supported by an Open DataLink
Interface (ODI) driver. For high throughput it is best to use an EISA NIC
or a 32 bit Microchannel NIC.
> The router must use a 386 or 486 based computer and has been optimized
for performance on such systems. For high throughput use at least a 25 Mhz
CPU and a large processor cache memory.
> MSDOS or PCDOS versions 3.1 or later.
> A minimum of 4M of RAM (additional RAM will improve performance), 20M
hard drive, and a high density floppy disk drive.
> A keyboard and monitor are required for initial installation, but are not
necessary for maintenance and management.
PACKET BURST
Burst Mode NLM resides on the file server. Once a connection has been
made, packets of data are transmitted in bursts, taking advantage of
available bandwidth.
The current implementation of Burst Mode requires:
- Burst Mode NLM to be loaded on the file server
- Space in conventional memory at the workstation level
- Burst Mode shell (BNETX.COM) to be installed on desired workstations
The appendix below lists the drivers that are Novell certified for use with
the Burst Mode performance enhancement. Contact the appropriate vendor to
ensure you have the latest driver and that it is certified for operation in
a bursting environment. For your protection, noncertified drivers should
be tested in Burst Mode before use in a live network.
Burst Overview
The amount of workstation memory needed is based on parameters given to the
shell by the user in the NET.CFG file, and the ability of the hardware.
The shell will determine upon loading whether the workstation has enough
memory. If there is enough memory, a packet burst connection is initiated
with the server by the client at connection/login time. (See the "How the
Algorithm Works" section below for memory requirements and the implications
of machine speed and performance.)
At connection time, maximum burst sizes are negotiated with each server
connected. Since packet burst is established with each connection, it is
possible to "burst" with one server while not bursting with another.
Once a burst connection is established between a workstation and a file
server, the workstation automatically uses the burst service when ever an
application makes a read or write involving more than 512 bytes of data.
This means that an application does not have to be burst aware.
Burst Transmission Rate Control Algorithm
Various factors influence the transmission rate of data on the network,
including the following:
- Speed of the file server
- Speed and available memory of the workstations
- Speed and buffer size of the network media
- Traffic on the network at transmission time
The Burst Mode NLM is sensitive to data transmission factors and
interaction between host network elements. For example, a fast file server
could overwhelm a congested bridge or slow workstation with a large stream
of packets, causing dropped packets. A bursting workstation is able to
give up a portion of the bandwidth it is using, if the network becomes
congested, and readjust to maximum bandwidth usage when it is available.
To maximize the fair and effective transmission rate, the packet burst
protocol uses a twofold transmission rate control algorithm.
How the Burst Algorithm Works
Packet burst uses conventional memory space in the workstation, for burst
buffers, even if the expanded or extended memory shell is loaded. The
amount of conventional memory, m, in bytes, required for one packet burst
buffer is:
m = negotiated packet size + 102
For the negotiated packet size value, NetWare negotiates a packet size with
Ethernet, for example, of 1024 bytes. The constant 102 is the total number
of bytes needed for the IPX, NCP burst, and ECB headers.
Thus, the total memory n required for all packet burst buffers, in bytes,
is:
n = pb buffers * m
The value pb buffers is the user-specified number of packet burst buffers
(see below), and m is the memory required for one packet burst buffer.
When a burst is received, the data is transferred from the hardware to the
workstation memory. To maximize performance, you must consider the speed
of the workstation as well as the network card being used. Performance
optimization, however, will be largely a matter of experimentation.
Packet burst is enabled at the workstation by adding a line to the
workstation's NET.CFG:
pb buffers = <n>
In this line, the variable n is a number between 0 and 10.
Making n = 0 disables packet burst, while 1 causes the shell to increase
the value up to 2.
If n > 10, the shell reduces the number to 10, rather than returning an
error.
Five to eight buffers is usually optimal. If the workstation does not have
enough memory for requested buffers, the shell sets the number using
available space, without notifying the user.
Increasing the value of n does not necessarily lead to better performance.
For example, a slow machine cannot move data from the on board buffers to
application memory fast enough, regardless of an increased n value. Also,
if a network card has on board receive buffers, the pb buffers parameter
could be set to a higher number than for cards without those buffers.
After figuring the maximum physical packet size and determining that there
is enough memory available at the workstation for the number of packet
burst buffers requested, the packet burst protocol determines a minimum
size for the packet burst data window and allows that minimum to be
transmitted regardless of network conditions. (Theoretical maximum window
size is 64KB)
Burst Connection Setup
A workstation sets up a packet burst connection with a file server at
attach/login time. Once the packet burst connection is established, it
stays up indefinitely. If the shell fails to make a packet burst
connection during attach/login, it uses normal NCPs to do the work. This
ensures compatibility with servers not running packet burst.
When the packet burst connection is made, the following sequence occurs:
1. Workstation and server synchronize (zero) packet and burst sequence
number.
2. They exchange packet burst connection Ids.
3. The workstation tells the server the dynamic IPX socket number it is
using for packet burst communication.
4. The two sides exchange information about the maximum sizes of packets
and bursts each can handle; both use the smaller packet and burst size.
Packet Burst is not actually invoked until a large read or write request is
made, regardless of when the connection is made.
Large Internet Packet Exchange NLM
The Large Internet Packet Exchange allows large packet size transmission
between server and workstation. Do not use Large Internet Packet Exchange
NLM with networks containing ARCnet network segments because the maximum
packet size on ARCnet is 512 bytes. This NLM does not recognize the
limitation and data would be lost.
Large Internet Packet Overview
When the workstation logs in or attaches to a file server, they must
negotiate a Maximum Packet Size value. This will be either the
workstation's Packet Buffer Size or the file server's Packet Buffer Size,
whichever is smaller. This is because the file server does not know if
routers between the workstation and file server can handle large packet
sizes. The Large Internet Packet Exchange NLM intercepts the Negotiate
Packet Size request and duplicates the original procedure exactly, except
that it ignores the router check.
After the Large Internet Packet Exchange NLM has been loaded on each file
server, workstations attaching or logging in can use large packet sizes.
If a router between the workstation and the file server is not configured
to handle larger packet sizes, the workstation will get the message "Error
Receiving from Network" the first time it tries to read or execute a file
larger than the router can handle. Retrying is useless, and aborting loses
the connection.
Since the NLM has no way of knowing when such a problem might exist, the
system supervisor must intervene to resolve such problems. There are four
ways to fix this problem:
1. Configure the router to handle larger packets.
2. Configure the workstation to use smaller packets.
3. Configure the server to use smaller packets.
4. Unload the Large Internet Packet Exchange NLM.
Only workstations attaching while the Large Internet Packet Exchange NLM is
loaded will be affected by it. When you load the Large Internet Packet
Exchange NLM, it becomes active. To deactivate the Large Internet Packet
Exchange NLM, unload it.
Service Advertising Filter
The Service Advertising Filter can be used to reduce the amount of Service
Advertising Protocol (SAP) traffic on the network by filtering
retransmission through routers. It involves the use of SAFILTER.NLM,
SAFENG.NLM and OBJTYPES.NLM.
SAP is used by servers and routers to inform all potential clients of the
server's presence on the network. Server is used here to mean a service
oriented process that may be running on a file server, router, or
workstation. Servers using the NLM broadcast their name and type every 60
seconds. NetWare routers (including file servers) rebroadcast SAP
information over each of their directly connected networks to ensure that
it is properly disbursed.
The primary clients of this information are file servers. Routers process
SAP information, but the file server stores it in the bindery for easy
access. A bindery object is created using the advertised name and type for
each advertising entity that does not reside on the server. The object
created is dynamic (it will get deleted when the file server is taken
down). These bindery objects are what is seen when running a utility such
as SYSCON, SLIST, or PCONSOLE to look at the list of known servers.
Basically, the Service Advertising Filter lets you determine what servers
will be visible at any given point in an internet. There are two main
reasons to do this:
1. To reduce the amount of network traffic generated by the SAP broadcasts.
On a large internet, the amount of traffic generated by SAP broadcasts can
become noticeable, especially on slower links. Also, large amounts of SAP
information can come to a file server from remote portions of the network
that its users never (or rarely) access.
2. For security. You may have some servers you don't want to be seen
except in specific cases.
The Service Advertising Filter NLM accomplishes its task by allowing you to
control any servers SAP information as it enters or leaves the router.
Using the Service Advertising flow control settings, routers and file
servers can be placed into one of four categories:
1. Open: a standard NetWare router or server without Service Advertising
Filter.
2. Gate: allows all incoming, but no outgoing SAP information. This
allows for a controlled crossover point between two otherwise independent
networks.
3. Exchange: does not allow SAP traffic in either direction. Since the
router continues to advertise itself, it is visible to two separate
networks, but provides no means of crossing over server information from
one to the other.
4. Other: a hybrid of the above. Generally, this would be a 'Gate'
configuration with some routers or servers allowed to be seen as if they
were an 'Open' configuration.
> SAFILTER.NLM
The SAFILTER.NLM allows you to administer device filter attributes for the
router on which it is loaded. It is not required for operation of the
filter engine, so it may be unloaded (or exited) after you have set up the
list. The following options appear in the menu:
- Filter List: This is the SAP filter permission list. It is a
scrollable list that contains the identity of devices that are allowed
to be passed through the filter. Servers are added to or removed from
the list by using the <Ins> and <Del> keys. When adding a server, the
New Filter Information form appears that asks for the name and type of
the server and its filter attributes (IN only or I/O).
- Load from/Save to a file: These options allow you to load a Filter
List from or to save the current list to a file. The default file
name is SYS:SYSTEM\ SAFILTER.DAT.
- Incoming SAPs ARE/ARE NOT Filtered: When incoming SAPs are
filtered, the filter list is used to screen SAPs entering the router
from an interface. If incoming SAPs are not filtered, all incoming
SAPs are passed through the interface. This overrides SAP Filter List
attributes.
- Outgoing SAPs ARE/ARE NOT Filtered: When outgoing SAPs are
filtered, the filter list is used to screen SAPs that have entered the
router from going into an interface. When not filtering, all SAPs are
allowed to pass to the outgoing interface. This overrides SAP Filter
List attributes.
> SAFENG.NLM
SAFENG.NLM must be loaded before any LAN drivers are bound to IPX for your
filter attributes to be enforced.
> OBJTYPES.NLM
OBJTYPES.NLM presents a scrollable list of object types, numbers, names,
and a flag indicating whether or not a type uses the Service Advertising
Filter NLM. The file provided contains the standard object types used by
Novell. This utility allows you to update the list as needed.
APPENDIX
Novell certified LAN and disk drivers released after NetWare 3.11 and
current as of 4/92. These drivers have been tested with the Burst Mode NLM
performance enhancement. Since certification is an on going process you
should consult NOVLIB (on CompuServe) and/or the hardware vendor for the
latest available driver information.
IMSPL2.ZIP and IMSPD.ZIP for disk Library
Dedicated IPX Drivers
Driver File Size Date
S3C503.OBJ 6,319 6-14-91
S3C505.OBJ 9,534 5-08-91
S3C523.OBJ 7,841 2-26-91
SLANSUP.OBJ 6,080 10-18-91
SNE2100.OBJ 4,802 2-19-91
SPCN2.OBJ 5,911 5-03-91
STOKEN.OBJ 6,683 8-23-91
DOS ODI Drivers
Driver File Size Date
3C1100.COM 12,288 11-12-91
3C501.COM 11,838 3-19-91
3C503.COM 14,821 6-14-91
3C505.COM 25,117 7-29-91
3C523.COM 12,238 7-29-91
EXOS.COM 20,194 11-08-91
LANSUP.COM 14,094 4-30-91
NE1000.COM 12,717 7-29-91
NE1500T.COM 21,840 10-11-91
NE2.COM 9,210 11-04-91
NE2-32.COM 12,737 7-29-91
NE2000.COM 13,018 6-03-91
NE2100.COM 21,836 10-11-91
NE3200.COM 19,242 9-03-91
PCN2L.COM 14,117 7-17-91
TOKEN.COM 15,663 6-14-91
TRXNET.COM 12,128 8-06-91
OSI LAN Drivers
Driver File Size Date
3C503.LAN 12,370 7-26-91
3C505.LAN 21,798 8-20-91
3C527.LAN 15,355 7-17-91
NE1000.LAN 11,857 7-25-91
NE1500T.LAN 16,406 10-09-91
NE2.LAN 15,548 11-11-91
NE2-32.LAN 12,185 7-25-91
NE2000.LAN 12,389 7-26-91
NE2100.LAN 16,405 10-09-91
NE3200.LAN 19,198 1-15-92
PCN2L.LAN 10,434 7-24-91
TOKEN.LAN 10,324 9-09-91
TOKENDMA.LAN 9,177 10-25-91
TRXNET.LAN 11,691 8-19-91
OS/2 ODI Drivers
Driver File Size Date
3C501.SYS 18,320 6-24-91
3C503.SYS 26,528 6-24-91
3C505.SYS 18,736 8-15-91
3C523.SYS 18,592 7-09-91
CMGRLAN.SYS 42,976 3-26-91
EXOS205.SYS 22,480 11-27-91
EXOS215.SYS 22,992 11-27-91
NE1000.SYS 19,424 6-24-91
NE1500T.SYS 21,008 12-13-91
NE2.SYS 20,448 6-24-91
NE2-32.SYS 19,568 6-24-91
NE2000.SYS 21,152 11-27-91
NE2100.SYS 20,992 12-13-91
PCN2L.SYS 13,632 10-11-91
TOKEN.SYS 25,392 12-13-91
TRXNET.SYS 21,824 12-17-91
TRXNET2.SYS 21,824 12-17-91